3.3 Packages that Change Keymaps

Viper is designed to coexist with all major and minor modes of Emacs. This means that bindings set by those modes are generally available with Viper (unless you explicitly prohibit them by setting viper-want-emacs-keys-in-vi and viper-want-emacs-keys-in-insert to nil). If viper-always is set to t (which is the default), Viper will try to bring each buffer in the Viper state that is most appropriate for that buffer. Usually, this would be the Vi state, but sometimes it could be the Insert state or the Emacs state.

Some major mode bindings will necessarily be overwritten by Viper. Indeed, in Vi state, most of the 1-character keys are used for Vi-style editing. This usually causes no problems because most packages designed for editing files typically do not bind such keys. Instead, they use key sequences that start with C-x and C-c. This is why it was so important for us to free up C-x and C-c. It is common for language-specific major modes to bind TAB and C-j (the line feed) keys to various formatting functions. This is extremely useful, but may require some getting used to for a Vi user. If you decide that this feature is not for you, you can re-bind these keys as explained earlier (see Customization).

Binding for TAB is one of the most unusual aspects of Viper for many novice users. In Emacs, TAB is used to format text and programs, and is extremely useful. For instance, hitting TAB causes the current line to be re-indented in accordance with the context. In programming, this is very important, since improper automatic indentation would immediately alert the programmer to a possible error. For instance, if a ) or a " is missing somewhere above the current line, TAB is likely to mis-indent the line.

For this reason, Viper doesn’t change the standard Emacs binding of TAB, thereby sacrificing Vi compatibility (except for users at level 1). Instead, in Viper, the key S-tab (shift+ tab) is chosen to emulate Vi’s TAB.

We should note that on some non-windowing terminals, Shift doesn’t modify the TAB key, so S-tab behaves as if it were TAB. In such a case, you will have to bind viper-insert-tab to some other convenient key.

Some packages, notably Dired, Gnus, Info, etc., attach special meaning to common keys like SPC, x, d, v, and others. This means that Vi command state is inappropriate for working with these packages. Fortunately, these modes operate on read-only buffers and are designed not for editing files, but for special-purpose browsing, reading news, mail, etc., and Vi commands are meaningless in these situations. For this reason, Viper doesn’t force Vi state on such major modes—it brings them in Emacs state. You can switch to Vi state by typing C-z if, for instance, you want to do Vi-style search in a buffer (although, usually, incremental search, which is bound to C-s, is sufficient in these situations). But you should then switch back to Emacs state if you plan to continue using these major modes productively. You can also switch to Vi temporarily, to execute just one command. This is done by typing C-c \. (In some of these modes, / and : are bound Vi-style, unless these keys perform essential duties.)

If you would like certain major modes to come up in Emacs state rather than Vi state (but Viper thinks otherwise), you should put these major modes on the viper-emacs-state-mode-list list and delete them from viper-vi-state-mode-list. Likewise, you can force Viper’s Insert state on a major mode by putting it in viper-insert-state-mode-list.

It is also possible to impose Vi on some major modes, even though they may bind common keys to specialized commands. This might make sense for modes that bind only a small number of common keys. For instance, Viper subverts the Shell mode by changing the bindings for C-m and C-d using viper-add-local-keys described in the section on customization (see Customization).

In some cases, some minor modes might override certain essential bindings in Vi command state. This is not a big problem because this can happen only in the beginning, when the minor mode kicks in. Typing M-x viper-mode will correct the situation. Viper knows about several such minor modes and takes care of them, so the above trick is usually not necessary. If you find that some minor mode, e.g., nasty-mode interferes with Viper, putting the following in your Viper customization file should fix the problem:

(viper-harness-minor-mode "nasty-mode")

The argument to viper-harness-minor-mode is the name of the file for the offending minor mode with the suffixes .el and .elc removed.

It may not be always obvious which minor mode is at fault. The only guidance here is to look into the file that defines the minor mode you are suspecting, say nasty-mode.el, and see if it has a variable called nasty-mode-map. Then check if there is a statement of the form

(define-key nasty-mode-map key function)

that binds the misbehaving keys. If so, use the above line to harness nasty-mode. If your suspicion is wrong, no harm is done if you harness a minor mode that doesn’t need to be harnessed.

It is recommended to harness even those minor modes that don’t override Viper keys, but still have their own keymaps. A general way to make a minor mode, my-mode, compatible with Viper is to have the file my-mode.el include the following code:

(when (fboundp 'viper-harness-minor-mode)
  (let ((lib (file-name-sans-extension
               (file-name-nondirectory load-file-name))))
    (viper-harness-minor-mode lib)))